Thanks for the review! I believe we should keep this change for the following reasons:

Immediate Assertions: Without clearing $_SESSION immediately, we cannot easily assert if the logout operation was actually successful within the same test method.

Simulating Real Flow: In production, destroy() is usually followed by a redirect, meaning the next request's $_SESSION is empty. Since CLI tests don't do real redirects, we need to clear it manually to simulate that post-logout state.

State Leakage in Complex Tests: Even with mockSession() in setUp(), if a single test method simulates multiple actions (e.g., logging out User A and then logging in User B), failing to clear the array causes state leakage between those actions.

Mock Usability: A test mock should help us verify application logic (that a session was successfully destroyed) rather than strictly mimicking the annoying limitations of PHP's native session_destroy().

Immediate Assertions: Without clearing $_SESSION immediately, we cannot easily assert if the logout operation was actually successful within the same test method.

In production, session_destroy() deletes the stored session data, but intentionally does not clear $_SESSION during the current request. A test expecting it to be immediately empty would therefore test behavior that production does not provide.

Simulating Real Flow: In production, destroy() is usually followed by a redirect, meaning the next request's $_SESSION is empty. Since CLI tests don't do real redirects, we need to clear it manually to simulate that post-logout state.

A redirect does not start the next request. It only tells the browser where to go. Session::destroy() should not simulate that next request only when ENVIRONMENT === 'testing'.

State Leakage in Complex Tests: Even with mockSession() in setUp(), if a single test method simulates multiple actions (e.g., logging out User A and then logging in User B), failing to clear the array causes state leakage between those actions.

Logging out one user and logging in another is authentication-level behavior, not merely session destruction. For example, Shield's logout implementation removes authentication data, regenerates the session ID, clears remember-me tokens, resets its internal authentication state, and intentionally keeps the session available for flash messages. An empty $_SESSION is therefore not a reliable way to verify that logout succeeded.

Mock Usability: A test mock should help us verify application logic (that a session was successfully destroyed) rather than strictly mimicking the annoying limitations of PHP's native session_destroy().

Test doubles should avoid external side effects, but their observable behavior should still match production. Otherwise, tests can pass for behavior that does not work in the application. Also, this changes Session itself, not only MockSession.